Special case comparisons between LazyRefs and bottom/top types #11069
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes scala#11064 When comparing a LazyRef with some other type, we need to force the LazyRef which can potentially lead to a cycle (as observed in scala#11064). However, in the situations ``` Nothing <: LazyRef(...) LazyRef(...) <: Any ``` we can skip that since the comparison is always true. This scheme fixes scala#11064, but it breaks down in similar situations if additional bounds are introduced (see neg/i11064.scala). So it is quite fragile. But it's probably the best we can do. The example in scala#11064 looks harmless, but type-theoretically it's actually a pretty explosive mix of F-bounded types and existential types (in Scala 2). In Scala 2, we need to force more for F-bounded types and we need to approximate existential types by dependent types, so not everything works the same way. My long term advice would be: get rid of F-bounds. Model them with intersections at the use site.
odersky
added
the
fasttrack
nicolasstucki
approved these changes
Jan 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #11064
When comparing a LazyRef with some other type, we need to force the LazyRef
which can potentially lead to a cycle (as observed in #11064). However, in the situations
we can skip that since the comparison is always true. This scheme fixes #11064, but it breaks
down in similar situations if additional bounds are introduced (see neg-custom-args/allow-deep-subtypes/i11064.scala).
So it is quite fragile. But it's probably the best we can do.
The example in #11064 looks harmless, but type-theoretically it's actually a pretty explosive
mix of F-bounded types and existential types (in Scala 2). In Scala 3, we need to force more
for F-bounded types and we need to approximate existential types by dependent types, so
not everything works the same way.
My long term advice would be: get rid of F-bounds. Model them with intersections at the
use site.